Data structure for control information on rewriteable data storage media

ABSTRACT

A data storage medium includes a data structure, called a disk control block, used for administration and control information for the data storage medium. One medium may contain multiple different disk control blocks, each addressing a different function. Each disk control block includes a control block identifier that specifies the function of the disk control block. Each control block also includes a set of standard access control parameters. If a drive encounters an unrecognized disk control block, the drive can still decode the standard control parameters, so that the drive behavior is not inconsistent with the requirements of the unrecognized disk control block.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a divisional application of Ser. No.09/921,024 filed on Aug. 2, 2001. application Ser. No. 09/921,024 ishereby incorporated herein by reference. application Ser. No. 09/921,024is a divisional application of Ser. No. 09/301,880 filed on Apr. 29,1999 now issued as U.S. Pat. No. 6,330,210. application Ser. No.09/301,880 is hereby incorporated herein by reference.

FIELD OF INVENTION

This invention relates generally to data storage media and morespecifically to data structures used for various identification andcontrol attributes for a rewriteable medium.

BACKGROUND OF THE INVENTION

A data storage medium typically includes an area for storage of variousadministration and control information, such as an identification of themedium, perhaps information regarding how the medium is partitioned intovarious separate sections, a directory or table of file names and dates,and perhaps information regarding access control. Administration andcontrol information may reside in a particular physical location on amedium separate from a general data storage area. For example, compactdiscs (CD) used for data storage have a single spiral track, with anarea near the start of the track called a lead-in area, and an area nearthe end of the track called a lead-out area. The information in thelead-in area and the lead-out area contains administration and controlinformation used only by drives and operating systems, and is separatefrom the area used for data storage.

Sometimes, a data storage medium has a format that is specific to aproprietary drive mechanism, or specific to one computer operatingsystem. Alternatively, some formats are defined by standards, so that amedium can be exchanged among drives from multiple manufacturers and maybe used by multiple computer operating systems. Standards are useful ineliminating unnecessary variation, but standards may also inhibitchange, even when change is needed. For example, CD's were originallydeveloped for read-only digital audio. As the CD technology was extendedto general data, and write-once media, and rewriteable media,accommodation of new features with backwards compatibility was always anissue. There is a need for a standard way of recording administrationand control information, for interchangeable rewriteable media, that canaccommodate unforseen needs for changes in the future.

SUMMARY OF THE INVENTION

One goal of the invention is to provide a standard, but very general andflexible, data structure for recording administration and controlinformation for a rewriteable storage medium, particularly when drivesand media may be provided by many different manufacturers. Accordingly,a data structure, called a Disk Control Block (DCB), is defined. Onemedium may contain multiple different DCB's, each addressing a differentfunction. Several examples of DCB's are provided. One example is calleda General Media (GM) DCB. The GM DCB contains information such as acounter that counts how many times the medium has been loaded, controlinformation for formatting of the medium by the drive, and powercalibration information. Another example DCB is called an Access Control(AC) DCB. An AC DCB may be used to partition a disk into multiplesections, and for each section the DCB defines an access attribute suchas write-once, or read only with password, or other similar accesscontrol. Another example is a DCB for updating firmware.

Another goal of the invention is to provide a data structure such thatif a drive encounters an unrecognized DCB, the drive can still decode anessential set of standard control parameters in the unrecognized DCB, sothat the drive behavior is not inconsistent with the requirements of theunrecognized DCB. Each DCB includes a control block identifier thatspecifies the function of the DCB. Each DCB also includes an area calledUnknown Content Descriptor Actions (UCDA), which specifies certainactions a drive must take if the drive does not recognize the identifierfor the DCB.

An additional goal of the invention is to ensure the reliability ofDCB's even if the disk is defective, or even if power is interruptedduring writing of a DCB. In an example embodiment, redundant DCB's areprovided, and each DCB has a sequence number. Identical identifiers withidentical sequence numbers indicate identical (deliberately redundant)DCB's. If one copy is invalid, the invalid copy is replaced by the validcopy. Identical identifiers with different sequence numbers indicatethat writing of a DCB was interrupted, and the DCB having the oldest(lowest) sequence number, for the particular identifier, is used.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a plan view of an optical disk in accordance with theinvention.

FIG. 2 is a block diagram of a Disk Control Block in accordance with theinvention.

FIG. 3 is a block diagram of a General Media Disk Control Block inaccordance with the invention.

FIG. 4 is a flow diagram of a method for using unknown Disk ControlBlocks.

FIG. 5 is a flow diagram of a process for recovery from power-failure ordata corruption in accordance with the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT OF THE INVENTION

In the following discussion, a proposed standard for optical disk mediais used to illustrate a specific example embodiment of the invention.However, the invention is equally applicable to any interchangeablerewriteable data storage medium. For example, the invention is equallyapplicable to tapes, removable magnetic disks or cards, or removablesemiconductor memory.

The proposed standard specifies a rewriteable interchangeable opticaldisk. A data structure called a Disk Control Block (DCB) is defined.There may be many types of DCB's; some may be defined by the proposedstandard, and others may be defined by individual manufacturers. Onetype of DCB, called a General Media (GM) DCB is defined by the proposedstandard. The proposed standard specifies that every compatible mediummust write one GM-DCB. All other types of DCB's are optional, and are inaddition to the GM-DCB.

The proposed optical disk medium is formatted into sectors, and sectorsare logically grouped into blocks. In the proposed standard, each sectoris 2 Kbytes (2,048 bytes) and each block is 16 sectors. A block is thesmallest unit of data that can be written. Error correction is performedon a block by block basis. In the proposed standard, a DCB is one block.In the specific example embodiment, DCB's reside within the lead-in andlead-out areas of an optical disk.

FIG. 1 illustrates the proposed disk medium. The proposed disk 100 has asingle spiral track 102, starting at an inner diameter and ending at anouter diameter. The spiral track has at least one lead-in area 104 andat least one lead-out area 106. One copy (108) of each DCB is written inthe lead-in area, and a redundant copy (110) is written in the lead-outarea. In the proposed standard, each lead-in or lead-out area canaccommodate up to 16 different DCB's (although there may be many morethan 16 DCB's defined). The GM DCB is written when the disk is firstformatted, and all other DCB's may be appended at a later time.

FIG. 2 illustrates a DCB 200 in accordance with the invention. Theproposed standard specifies a standard header. The header contains threeinformation items: (1) a DCB ID number (202), (2) an Unknown ContentDescriptor Actions (UCDA) area (204), and (3) a vendor ID (206). Theremaining part 208 of the DCB is specific to the type of DCB identifiedby the DCB ID number. The DCB ID number is a number that must beregistered as part of the standard. However, as will be discussed inmore detail below, new DCB ID's may be added during the life of thestandard, and it is not necessary for every drive to recognize every DCBID. The proposed standard reserves one 16-bit word for the DCB ID. Theproposed standard specifies that all DCB blocks are initially formattedas all zeros. Therefore, a DCB ID of 0000 hex indicates an unused(available) block. If a drive is unable to write a DCB, for examplebecause of a media defect, the DCB ID is set to all ones (FFFF hex). Ifa DCB is no longer needed, rather than rewriting the block with allzeros, the DCB ID is set to FFFE hex, which indicates the block isavailable for reuse. Note that because of possible media defects, thesequence of DCB's in the lead-in area may be different than the sequenceof DCB's in the lead-out area. For example, if the first DCB block ofthe lead-in area is defective, the GM DCB may be the second block in thelead-in area but may be the first block in the lead-out area.

One important feature of a DCB is the second header entry, UnknownContent Descriptor Actions (UCDA) 204. The UCDA is used to ensure thateven if a drive does not recognize a DCB ID, the drive does not permitdisk access actions that are inconsistent with the access controlrequirements of the unknown DCB. This provides some backwardscompatibility, a capability that is lacking in many current proposedstandards. The UCDA will be discussed in more detail below. The thirdand final entry in DCB header is a vendor ID (206).

FIG. 3 illustrates additional detail for the GM DCB (300). The GM DCB ofcourse has the standard header (302, 304, 306). The following list ofentries in the GM DCB specific area are intended as illustrations, andthe actual list and order may change as the standard is defined. In theGM DCB-specific area illustrated in FIG. 3, the first example entry 308is a sequence number. The sequence number is used for recovery fromcorrupted data or a power failure, and will be discussed in more detailbelow. The second example entry 310 in the GM DCB specific area is amedia serial number. The third example entry 312 is a load count, whichindicates the number of times the medium has been inserted into a drive.Optical disks envisioned for use in conjunction with the invention maycontain up to approximately 17 Gigabytes of data. It is expensive, ifnot impractical, to preformat every medium. Accordingly, each medium maybe formatted by a drive. It is known for optical disk formatting tooccur as a background activity when a drive is otherwise idle. Thefourth example parameter (314) for a GM DCB is a parameter that enablesbackground fill (formatting). The next example parameter (316) is apointer to the next block that has not been formatted. The drive mayalso check for media defects (certification) in the background byperforming a read operation on each block after it has been formatted(or perhaps a real-time read-after write operation). The sixth exampleparameter (318) for a GM DCB is a parameter that enables backgroundmedia certification. The seventh (320) example parameter is a pointer tothe next block that has not been certified.

Some present optical disk technologies require that the laser writingpower be calibrated before writing can occur. In general, the powerrequired is a function of the specific medium and the particularelectronic components in the drive. In general, power calibration istime consuming. Another proposed variable (not illustrated) in the GMDCB is at least one entry for a drive identification and a numberdesignating the laser power resulting when the laser power wascalibrated using the specific medium in the identified drive. A driverecognizing its own ID in the GM-DCB can then simply read the requiredlaser power without having to recalibrate.

Operating systems may control whether or not a file can be read orwritten by a user. Some files may be password protected by the operatingsystem. Alternatively, write protect for an entire medium may becontrolled mechanically. For example, a sliding tab on a flexible diskcartridge, or a ring inserted into a tape reel may be used to preventwriting to a medium. In general, if an interchangeable medium is placedinto a computer system using an incompatible operating system, accesscontrol specified by the operating system may be bypassed. For example,if one operating system write protects a file, a different operatingsystem may permit the file to be overwritten. Moving control of accessinto the drive provides some additional protection. Access controlwithin a drive is not new. For example, U.S. Pat. No. 5,233,576 (Curtiset al.) describes an optical disk medium in which the medium can bepartitioned into different portions, and each portion can be defined aswritable, or read-only. One attractive feature of Curtis et al. is thatthe method of write protection works even for legacy drives that weremanufactured before the new access control method was available. Oneexample DCB for use by the present invention takes this general concepteven further. One example optional DCB is an Access Control (AC) DCB. Anaccess control DCB divides the disk into regions, by specifying startingand ending logical block address or by specifying starting block addressand number of blocks. Each region, as seen by the operating system, mayrepresent a file, a directory, the entire disk, or any other logicalstorage construct. Each region has an associated access controlspecification, where the access control specifications include thefollowing, as examples:

-   -   No restrictions    -   No read    -   No write    -   No format    -   Write-once    -   Read with password    -   Write with password    -   Format with password    -   Appendable with password

The above list is just a list of examples, and other access controls maybe desirable. For example, one issue is whether a control attributespecifying a write-once region can ever be reversed. The proposedstandard specifies that controls can be changed, so there are controlson controls. For example, an access control, within a AC DCB, may itselfbe password protected.

Now return to the UCDA (FIG. 2, 204). The UCDA contains single bitfields, where each bit specifies an access control attribute. The UCDAis used only when a drive does not recognize a DCB ID, and thereforecannot interpret any information, or specifically cannot interpretaccess control information within the DCB-specific area of the DCB. Whena drive does not recognize a DCB ID, the UCDA for the unrecognized DCBoverrides all other access controls in all DCB's. For example, assume anewly defined DCB specifies that a region of the disk must be writeprotected. The new DCB specifying a write protect region also has a bitset in its UCDA area that specifies no writing. If the drive does notrecognize the new DCB ID, the drive still sees that the UCDA specifiesno writing, and the drive then does not permit any part of the disk tobe written. This ensures that the drive does not perform any accessactivity that is inconsistent with the access requirements of anunrecognized DCB. For an additional example, a unknown DCB may disablereading of the DCB specific area of the DCB to ensure that a password inthe DCB cannot be read by unauthorized drives. Specific UCDA bits may,for example, disable writing within the DCB area of the lead-in andlead-out areas, disable writing with the data area of the disk, disablewriting to any part of the disk, disable overwriting of the data area,disable reformatting, disable reading of the data area, and so forth.

FIG. 4 illustrates a method for use with the UCDA. A drive first readsthe DCB ID (step 400). If the drive recognizes the ID (step 402), thenthe drive uses the DCB-specific data area (step 404). If the ID is notrecognized (step 402), the drive must use the UCDA access controlinformation in the header (step 406).

Another proposed DCB type is a firmware update DCB. Typically, drivefirmware is updated by connecting a drive to a computer and having thecomputer send a new version of firmware. Often, it is more convenient ifa firmware update can occur without involvement by a host computer. Itis known for a drive to recognize a special medium having a new versionof firmware for the drive. The drive replaces its existing firmware withthe new firmware read from the special medium. A DCB may be defined thatidentifies a medium as a firmware update medium, and containsinformation describing the firmware update, version information, backversion compatibiity, and so forth.

Since DCB's are so critical to the proposed standard, it is important toprovide some protection against a loss-of-power during writing of a DCB,or protection against some other corruption of a DCB. As stated above,one redundant DCB is written for each DCB. The first word of eachDCB-specific data area is a sequence number (FIG. 3, 308). For example,when a DCB is written for the first time, it might have a sequencenumber of one. Each copy of the DCB receives the same sequence number.If the DCB is subsequently updated, the sequence number is incremented.Assume, for example, that a DCB having a sequence number of two iswritten into the lead-in area, and then power is lost while writing thecopy in the lead-out area.

FIG. 5 illustrates a method of ensuring that there are always two validcopies of each DCB. A drive can check DCB validity by checking the blockerror correction data. If both blocks are valid (FIG. 5, step 502), andif both sequence numbers are the same (step 504), then no remedialaction is required. If both blocks are valid (step 502), but thesequence numbers are different (step 504), then power may have beeninterrupted before a copy could be made. The copy having the lowersequence number is then replaced by the copy having the higher sequencenumber (step 506). If at least one copy is not valid (step 502), but atleast one copy is valid (step 508), then the invalid copy is replaced bythe valid copy (step 510). If both copies are invalid (step 508), thenan error condition has occurred, and automatic remedial action is notpossible.

From the above, it can be seen that DCB's provide a flexible andstandard way of providing administration and control information for adata storage medium, particularly when drives and media may be providedmy many different manufacturers. In addition, the use of UCDA's providesa standard way of ensuring that a drive does not perform an access thatis inconsistent with a DCB, even if the DCB is not recognized. Finally,redundancy and sequence numbers provide some protection againstcorrupted DCB's.

The foregoing description of the present invention has been presentedfor purposes of illustration and description. It is not intended to beexhaustive or to limit the invention to the precise form disclosed, andother modifications and variations may be possible in light of the aboveteachings. The embodiment was chosen and described in order to bestexplain the principles of the invention and its practical application tothereby enable others skilled in the art to best utilize the inventionin various embodiments and various modifications as are suited to theparticular use contemplated. It is intended that the appended claims beconstrued to include other alternative embodiments of the inventionexcept insofar as limited by the prior art.

1. A data storage medium for being accessed by a drive, said datastorage medium comprising: a control information block which includes:at least one defined region; and control bits for enabling the drive toaccess said at least one defined region; wherein: said control bits arerecorded in ECC blocks; said control bits are allocated into diskcontrol blocks; each of said at least one defined region is providedwith an associated access control specification; and a redundant diskcontrol block is provided as a copy of each of the disk control blocks.